COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.<<ebos[w86,jmc]		Ideas for the editor-based operating system>>
C00013 00003	Notes:
C00014 ENDMK
C⊗;
.<<ebos[w86,jmc]		Ideas for the editor-based operating system>>
.require "memo.pub[let,jmc]" source;
.cb EBOS - A Projected Editor-Based Operating System

.cb "by John McCarthy, Stanford University"

	In our view present operating systems are obsolete in a variety
of ways.  This condemnation includes WAITS, ITS, TOPS-20, UNIX, MULTICS,
and VM.  Here are some principles for a new one.
.item←0

	#. While some of the proposed features exist in present systems,
these systems have grown gradually and are not integrated wholes.  Perhaps
MULTICS is an exception here, but its authors chose to emphasize security
features that have not been important for generally used operating
systems.  Some other efforts to plan a system from scratch have failed, largely
because they got too complicated.  This one will be kept as simple as
is compatible with its objectives.

	#. The command language will be a sugared programming language ---
in fact, sugared Lisp.  The user will have the full capability of
Lisp in compounding the basic operations into command programs, i.e.
macros (called execs in IBMese).  In our examples, we sugar the Lisp
by using conventional functional notation, but "command programs"
will have Lisp internal notation format.  Whether they will be
represented as list structure isn't decided.
  File operations, compiling, etc. will
be treated as functions, e.g. one will have statements like

	foo.bin := fortran(foo.for).

The function  fortran  then represents the effect of the Fortran compiler
and can be composed with other functions.  The Unix pipes provide for
composition of functions but in a non-standard syntax and make the curious
assumption that all functions are unary.
We will consider carrying this functional idea to an extreme.  Namely,
typing a single text character to a text editor may be regarded as
executing an assignment statement of the form

	file := insert(file,char,place).

Operations on files are also obvious candidates to be regarded
assignment statements and will be compoundable in such statements as

	foo.bin,foo.error := fortran(append(foo1.for,precompile(foo2.alg)).

	The requirement of programmability means that whatever
compound operations the user can do himself, he can conveniently
make command programs do for him.  Of course, it must be convenient
to include conditionals in command programs, and this is where most
macro and exec systems fall down.  Conditionals are an afterthought
and are done awkwardly.  Keeping the command language programmable
is to have a higher priority than making the system controllable by
the mouse.  Thus any control operations involving a mouse are sugared
versions of the basic language.

	#. The sugaring will be both syntactic and semantic.  Syntactically,
one will simply type the character while in a context in which typing the
character inserts it in the file.  Other operations will be sugared in
appropriate ways, e.g. one can write

	fortran(foo)

for the above assignment statement.

	#. By semantic sugar we mean that in appropriate contexts, the
operations that are the most obvious interpretations of the base forms
are not carried out, but something easier is done.  For example, (2)
above doesn't make a new copy of the file, but merely inserts a character
in the core image of the file.

	#. By editor-based, we mean that the user is always interacting
with the system via a powerful editor, e.g. something like EMACS.  All
input is available in the editor for re-editing and re-submission, and
all output is available for editing.  This facility has been useful
in the E editor on WAITS but requires substantial expansion.
Most interactive programs will be able to forgo editing features of their
own, thus simplifying them.  Naturally, certain programs will want to do
their own editing.

	#. It is time to allow the user arbitrary character sets.  This
presents no difficulty for the internal operation of editors, and only
requires that they admit and recognize that some characters are represented
by multiple bytes.  Similarly bit map displays (IBMese APA displays)
allow the display of arbitrary characters.

	#. The major problem in allowing arbitrary character sets
involves keyboards.  We will discuss this further later, but for
now we only point out the goal that special keyboards emphasizing
a particular character sets will be kept entirely compatible with
getting the special characters on general purpose keyboards built
by people with no ideas about the particular character set.  Indeed
neither the operating system nor the users program need know which
kind of keyboard is being used.

	#. Present small computer operating systems were designed
in the era of small memories and purport to keep this fact invisible
to the user.  For example, Unix was designed for the PDP-11 that has
32K 16 bit words of addressability.  The effect is that simple operations
involve multiple disk operations and are distressingly slow.  EBOS
will take advantage of large memories; we are quite prepared to make
a system that won't run with less than 4 megabytes if that will make
the system run faster and more smoothly.  The basic technique is
to keep large amounts of directory information in main memory while
the system is running.  If a user's command refers to certain files,
our goal is that the only disk operations executed are those that
read and write those specific files.

	#. The system will be designed to be efficient with very
large numbers of files and with very large files.  If a reader
wishes to treat a book as a single file, that should work efficiently.

	[It is our opinion that paging has basically failed in its
goal of making small memories look like large ones.  It is useful
mainly as a means of address translation, and introduces inefficiencies
even when used for that.  The fastest computers, i.e. the Crays, don't
use it.  However, it looks like EBOS will be implemented on computers
that have paging, so we'll have to minimize the effects of its
inefficiencies.  The same remarks apply to a lesser degree to caches.
In the long run it will probably turn out that memory hierarchies
are more efficiently handled by compiled software than by built-in
hardware features].


.cb THE PRESENT EBOS PROJECT

	Our present plan is to do the EBOS project on the IBM RT-PC
computer using the Berkeley Unix 4.2 kernel.  Thus EBOS will be a
Unix shell.  Present indications are that we won't lose too much
in functionality or efficiency by this compromise with sin.
The programming language will be some variety of Common Lisp.

This file is ebos[w86,jmc] and was pubbed on {date} at {time}.
Notes:

declarative information
editor functions are programs and can be used by programs
directories as data structures
programs communicating with one another
telnet etc. available to programs